src/main/java/org/example/projektarendehantering/application/service/CaseService.java (1)

213-220: No mechanism to un-assign owner or handler.

The current logic only sets ownerId/handlerId when the DTO field is non-null. Combined with the controller ignoring empty strings, there's no way to clear an assignment (set back to "Unassigned").

If un-assignment is a required feature, consider using a sentinel value or separate clear flags:

♻️ Potential approach to support clearing

One option is to distinguish between "not provided" (null) and "explicitly cleared" (e.g., a dedicated field or accepting empty UUID):

// In CaseAssignmentDTO, add flags:
private boolean clearOwnerId;
private boolean clearHandlerId;

// In assignUsers:
if (dto.isClearOwnerId()) {
    entity.setOwnerId(null);
} else if (dto.getOwnerId() != null) {
    // existing validation and set
}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/org/example/projektarendehantering/application/service/CaseService.java`
around lines 213 - 220, The current logic only updates owner/handler when
dto.getOwnerId()/dto.getHandlerId() are non-null, so there's no way to clear
assignments; add boolean flags (e.g., isClearOwnerId/isClearHandlerId) to the
DTO and update the assignment logic in the service: for owner use if
(dto.isClearOwnerId()) { entity.setOwnerId(null); } else if (dto.getOwnerId() !=
null) { UUID ownerId = requireEmployeeWithRole(dto.getOwnerId(),
Set.of(Role.DOCTOR), "ownerId"); entity.setOwnerId(ownerId); } and similarly for
handler (use isClearHandlerId, requireEmployeeWithRole for Role.NURSE, and
entity.setHandlerId(null)/setHandlerId(handlerId)) so clearing is explicit and
validation only runs when assigning.

src/main/resources/templates/cases/detail.html (1)

38-58: Consider restricting assignment form visibility by role.

The assignment form is visible to anyone who can view the case, but CaseService.assignUsers only allows managers and doctors to submit assignments. Nurses will see the form but get an authorization error upon submission.

Consider conditionally rendering this section based on user role to avoid a confusing UX:

<div th:if="${currentUser.role.name() == 'MANAGER' or currentUser.role.name() == 'DOCTOR'}">
    <!-- assignment form here -->
</div>

This requires passing the current user/role to the model.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/resources/templates/cases/detail.html` around lines 38 - 58, The
assignment form should be conditionally rendered so only managers and doctors
see it; wrap the form in a Thymeleaf condition (e.g.,
th:if="${currentUser.role.name() == 'MANAGER' or currentUser.role.name() ==
'DOCTOR'}") in the template (detail.html) and ensure the controller that
prepares the model for this view adds the currentUser or currentUser.role (so
the template can evaluate currentUser.role.name()); this aligns the UI with the
CaseService.assignUsers authorization and prevents nurses from seeing the submit
form that would produce an auth error.

src/test/java/org/example/projektarendehantering/application/service/CaseServiceTest.java (1)

500-515: Test coverage gap: status transitions to HANDLER_ASSIGNED even without a handler.

This test correctly verifies the status change when a handler is assigned. However, the current assignUsers implementation (lines 223-228 in CaseService) transitions to HANDLER_ASSIGNED whenever the previous status isn't already HANDLER_ASSIGNED, regardless of whether a handler is actually being set.

Consider adding a test case that verifies the expected behavior when only ownerId is provided (no handler):

`@Test`
void assignUsers_shouldNotChangeStatusWhenOnlyOwnerAssigned() {
    caseEntity.setStatus(CaseStatus.CREATED);
    CaseAssignmentDTO dto = new CaseAssignmentDTO();
    dto.setOwnerId(doctorActor.userId()); // No handlerId
    // ... verify status remains CREATED or changes appropriately
}

If transitioning to HANDLER_ASSIGNED without a handler is unintended, see the related comment on CaseService.java.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/test/java/org/example/projektarendehantering/application/service/CaseServiceTest.java`
around lines 500 - 515, The current assignUsers behavior allows CaseStatus to
move to HANDLER_ASSIGNED even when no handler is provided; add a unit test named
assignUsers_shouldNotChangeStatusWhenOnlyOwnerAssigned that sets
caseEntity.status to CREATED, builds a CaseAssignmentDTO with only ownerId (no
handlerId), mocks repositories similarly to the existing test, calls
CaseService.assignUsers, and asserts the status remains CREATED (and verify
auditService not recording a CREATED -> HANDLER_ASSIGNED transition); if
behavior is unintended, modify CaseService.assignUsers to only set
CaseStatus.HANDLER_ASSIGNED when dto.getHandlerId() is present (and resolution
logic still saves/maps/audits consistently).

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/main/java/org/example/projektarendehantering/presentation/web/UiController.java (1)

140-148: ⚠️ Potential issue | 🟡 Minor

Preserve the invalid parameter name in the 400 response.

Lines 140-148 now catch malformed UUIDs, but "Invalid UUID format" still hides whether ownerId or handlerId was bad. That makes the form/API error harder to correct.

Suggested fix

-        try {
-            if (ownerId != null && !ownerId.isBlank()) {
-                dto.setOwnerId(UUID.fromString(ownerId));
-            }
-            if (handlerId != null && !handlerId.isBlank()) {
-                dto.setHandlerId(UUID.fromString(handlerId));
-            }
-        } catch (IllegalArgumentException e) {
-            throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "Invalid UUID format");
-        }
+        if (ownerId != null && !ownerId.isBlank()) {
+            try {
+                dto.setOwnerId(UUID.fromString(ownerId));
+            } catch (IllegalArgumentException e) {
+                throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "Invalid ownerId UUID");
+            }
+        }
+        if (handlerId != null && !handlerId.isBlank()) {
+            try {
+                dto.setHandlerId(UUID.fromString(handlerId));
+            } catch (IllegalArgumentException e) {
+                throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "Invalid handlerId UUID");
+            }
+        }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/org/example/projektarendehantering/presentation/web/UiController.java`
around lines 140 - 148, The catch block in UiController that wraps
dto.setOwnerId(UUID.fromString(ownerId)) and
dto.setHandlerId(UUID.fromString(handlerId)) should return which parameter
caused the bad UUID; change the logic to validate/parse ownerId and handlerId
separately (or catch exceptions per parse) and throw a
ResponseStatusException(HttpStatus.BAD_REQUEST, "Invalid UUID format for
ownerId") or "... for handlerId" as appropriate so the 400 message preserves the
invalid parameter name.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes